IBIS Macromodel Task Group Meeting date: 28 November 2017 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad reviewed the schedule for upcoming ATM meetings. The group plans to cancel the meetings on December 26th and January 2nd. All other meetings in December will be held as usual. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Curtis: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189 - File_TS reference terminal connection to node 0? - Arpad: [Sharing his recent email describing his new proposal] - Background: My observation is that even if we make a note or warning about consistency of usage, "either use node 0 as a reference for everything or not at all", we will have trouble in practice. - Suggesting or enforcing consistency requirements is impossible if the user has models from multiple vendors in the same simulation. - Also, we aren't going to change the IBIS-ISS specification now and disallow an IBIS-ISS subcircuit from connecting to node 0 internally, so we have another consistency issue. - [sharing a picture of a 4 port (5 Terminal) package connecting two power pins to two power pads] - If we don't provide a way for the user to connect the N+1 (5th) terminal to node 0, someone might be tempted to use their Vss pin as the reference. But that would essentially short that port with its own reference (that port's two terminals would be the same). - Therefore, I think we need a way to specify ideal node 0 as a reference. - Proposal: - New Terminal_type called Ref_node. (used to connect to ideal node 0) - New Terminal_type_qualifier called node_name. - New Qualifier_entry rule. When the Terminal_type_qualifier is node_name the shall be A_gnd. (use A_gnd from [External Model]). - New rule: Aggressor_Only is not allowed with Terminal_type Ref_node. - At the end of the Aggressor_Only section add the following rule and warning: Terminal_type Ref_node is not required for File_TS or File_IBIS-ISS, but if present, File_TS may only have it only on the N+1th terminal line (once), while File_IBIS-ISS may have it on any of its terminal lines any number of times. Important: It is highly recommended to not use A_gnd for referencing purposes on terminal lines and to not use ideal ground (node0) connections inside IBIS-ISS subcircuits. - Walter: I agree with the functionality you're looking to add, i.e., the ability to connect a node in File_TS or multiple nodes for IBIS-ISS to node 0. - What's the easiest way to implement this in terms of text of the BIRD, ease for the model maker, and ease for the EDA tool? - What if we just say, "If Terminal_type is A_gnd, then it's ideal node 0." - Arpad: Just make Terminal_type itself A_gnd? - Yes, I think that's simpler, and it would eliminate most of my new rules and changes. But the final rule and warning would largely be the same? - Walter: I think it would be easier to state that A_gnd is only allowed on terminal N+1 of a File_TS. - Arpad: Walter's suggestion is fine by me. I'm happy to consider changes. - Bob: Walter's suggestion is valid and simplifies the proposal. - Aggressor_Only is automatically excluded when Terminal_type is A_gnd, because it's only for I/O terminals. - Radek: One of the suggestions I'd made for dealing with the issue of node 0 appearing in an IBIS-ISS was to make sure node 0 was available to the rest of the circuit. - But just exposing A_gnd is not the end of the story. You still have to make sure A_gnd (node 0) is present among the nodes the interconnect model is actually modeling. - If you just let one component connect to A_gnd, you have the same ambiguity we discussed regarding File_TS0. - We have to be precise about how many components in the model need to be connected to the various nodes. Only the buffer terminals and pin terminals can appear only once. All of the other nodes must appear at least twice in order to guarantee proper connectivity. - Walter: I think one of the requirements (maybe implicit) of BIRD189 is that you should be able to use it to wrap package models that are currently being developed. BIRD189 should be able to wrap them in a way that is compatible with the way people are making and using them today. - I think you'll almost always find that models reference node 0. They reference node 0 on their W-lines, S-parameters, capacitors, etc. - It's valid to argue that this may be incorrect for power-aware simulations. But even that is not necessarily true. Scott sent out a very detailed explanation about how you can use ground based power-aware simulations and get perfectly valid results. - So, to say "it is highly recommended to NOT use A_gnd" is incompatible with the way people make models today. I think it would be okay to note that since power-aware simulations are becoming more important, one should not use A_gnd in an attempt to do power aware simulations without using ground based simulation techniques. - Radek: We are talking about two different things. - You make a measurement with respect to your ground (set by the measurement). - In the simulation, you either have the same environment as measurement, or if you're using that model elsewhere you have to connect that ground to something meaningful for your circuit. You can't just connect it to global ground without any regard for the real schematic ground (local ground) chosen by the user for the area the interconnect model is covering. - If you want to be able to connect to global ground, with no knowledge or concern for where the local circuit is, then you need the restrictions on the Touchstone data that I defined during the File_TS0 discussions. - Walter: I'm just trying to quantify the requirement you want. - What I said was if you do ground-referenced power modeling, meaning you take Vss and everything "0" and tie those nodes to ideal node 0 (so you can say Vss is 0V relative to ideal node 0), then everything can work fine. If the simulator did that, then everything is fine and it can do power-aware simulations. You just have to adjust the PDN models for Vdd, but that is what people are doing today. - Arpad: I understand your point. But I see a dilemma here. - We basically have two modeling styles, the ground-referenced style, in which all the parasitics are rolled into the upper (power) side of the model, and the other style in which power and ground parasitics are kept separate as an inductance loop. - In order to do one or the other style, the entire simulation deck has to follow the same convention. Can we talk about consistency if the user might have to simulate with models from different vendors made one way or the other way? How can we best verbalize the warning? - Radek: The warning is fine. You are saying there's an issue, and there's a requirement if conditions aren't met. It tells people it's perhaps best not to use node 0. - Bob: If we go with Arpad's proposal, with Walter's simplifying modification, then the warning is easy to check for A_gnd. Any time A_gnd shows up as a Terminal_type, it's a warning. But catching use of node 0 in IBIS-ISS subcircuits or detecting another Touchstone file with an N+1 terminal that isn't connected to node 0 is hard, so detecting incompatibilities is hard. - Discussion: The group discussed the wording of a warning sentence to be included in the BIRD and arrived at: "Power-aware simulations may require that A_gnd NOT be used as a reference for interconnect models, or that ideal ground (node0) NOT be used inside IBIS-ISS subcircuits." With the group's approval, Arpad took the AR to write up a new draft of the BIRD for discussion at the Interconnect Meeting the following day. Bob noted that there would be additional vetting to do. - Arpad: If this BIRD189 discussion now moves back to Interconnect, what topics should we discuss next week? - Walter: I think item #8 (single ended applications of AMI - DDR5) should be tabled. Everyone understands that there are various issues that may make it invalid. But it's still unclear what should be done. - Discussion: Walter moved to table item #8. Radek seconded. No one was opposed. Bob said he thought item #7 (C_comp improvements) should be tabled until BIRD189 is finalized. Bob moved to table item #7. Walter seconded. No one was opposed. - Arpad: All our topics are tabled. - We will continue to hold the meeting and discuss topics as they arise, perhaps related to or suggested by Interconnect meetings. - Mike L.: I'd like to add an item to discuss Forward Error Correction. I can give a presentation on what I've heard from Asia. - Bob: I'd like to review a presentation by Raymond Chen. http://ibis.org/summits/jun05/chen.pdf - Arpad: Let's all review that presentation for next week's discussion. - Thank you all for joining. AR: Arpad to prepare BIRD189.5_draft11_v2 with his proposed A_gnd changes. ------------- Next meeting: 05 December 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives